System and method for secure control of resources of wireless mobile communication devices

ABSTRACT

Systems and methods for secure control of a wireless mobile communication device are disclosed. Each of a plurality of domains includes at least one wireless mobile communication device asset. When a request to perform an operation affecting at least one of the assets is received, it is determined whether the request is permitted by the domain that includes the at least one affected asset, by determining whether the entity with which the request originated has a trust relationship with the domain, for example. The operation is completed where it is permitted by the domain. Wireless mobile communication device assets include software applications, persistent data, communication pipes, and configuration data, properties or user or subscriber profiles.

TECHNICAL FIELD

This invention relates generally to wireless mobile communicationdevices, and in particular to providing security for such devices.

BACKGROUND ART

When personal computers (PCs) were first introduced, one of theirgreatest appeals was that the machine was controlled by its user. Thiswas in stark contract to the mainframe model, where multiple usersshared a single machine. Resources on a mainframe computer werecarefully shared between users by the operating system. On a PC having asingle user at any time, this type of partitioning of resources was notnecessary. As the PC began to displace the corporate mainframe computer,however, issues of control began to re-emerge. Corporate InformationTechnology (IT) departments, increasingly saw the desktop PC as part ofthe corporate infrastructure. This caused tension between an originalgoal of the PC revolution, that the user controls their own computer,and the new role they played in the corporation. This conflict continuestoday and is played out on a regular basis in companies around theworld.

A similar tension exists with handheld and other portable computers.Such as wireless mobile communication devices. However, the situationwith handheld computers is more complex for several reasons. Sincehandheld computers are becoming relatively inexpensive, many userspurchase such devices for personal use. Such user-purchased devicescannot be said to be owned by a corporation of which the user is anemployee, but they often come to contain corporate data such ascontacts, calendar entries and email. Even when a handheld computer ispurchased by a corporate employer and provided to an employee, thehandheld computer is likely to be used outside the corporate premises.This may require external access to the corporate infrastructure.Allowing an unsecured device to access the corporate network offerspotential for security breaches. Furthermore, when a handheld computeris enabled for wireless communications, a carrier becomes anotherinterested party with respect to the handheld computer. The carrier ownsand operates a wireless communication network in which the handheldcomputer is configured to operate, and therefore may want to exercisecontrol over the traffic on that network. As well, the carrier may wishto add to their revenue by offering additional services to handheldcomputers. A carrier may thus be at odds with a corporate IT departmentin regard to handheld computer control, particularly where IT departmentcontrols may potentially increase network traffic or affect thecarrier's ability to offer these services and thus reduce their revenue.

Therefore, there remains a need for a system and method for securecontrol of a wireless communication device, which allows each individualstakeholders, including the user, corporate owner or corporate systemoperator, carrier, and possibly other stakeholders, to control theirdevice assets without affecting the other stakeholders.

DISCLOSURE OF INVENTION

According to an aspect of the invention, a system for secure control ofa wireless mobile communication device comprises at least one domain,each domain including an asset of the wireless mobile communicationdevice, and a domain controller configured to receive a request toperform-an operation affecting at least one of the assets, to determinewhether the request originated with an entity that has a trustrelationship with the domain that includes the at least one affectedasset, and to permit completion of the operation where the requestoriginated with an entity that has a trust relationship with the domainthat includes the at least one affected asset.

In accordance with another aspect of the invention, a method for securecontrol of a wireless mobile communication device, comprises segregatingassets of the wireless mobile communication device into a plurality ofdomains, each domain including at least one asset of the wireless mobilecommunication device, receiving a request to perform an operationaffecting at least one of the assets, determining whether the operationis permitted by the domain that includes the affected asset, andallowing the operation to be completed where the operation is permittedby the domain that includes the affected asset.

Further features of secure control systems and methods will be describedor will become apparent in the course of the following detaileddescription.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a communication system in whichwireless mobile communication devices may be used.

FIG. 2 is a block diagram of an exemplary wireless mobile communicationdevice in which a system and method for secure control may beimplemented.

FIG. 3 is a block diagram illustrating multiple domains on a wirelessmobile communication device.

FIG. 4 is a flow diagram showing a method for secure control of awireless mobile communication device.

FIG. 5 is a block diagram of an example wireless mobile communicationdevice.

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 is a block diagram showing a communication system in whichwireless mobile communication devices may be used. The communicationsystem 10 includes a Wide Area Network (WAN) 12, coupled to a computersystem 14, a wireless network gateway 16 and a corporate Local AreaNetwork (LAN) 18. The wireless network gateway 16 is also connected to awireless communication network 20 in which a wireless mobilecommunication device 22 (“mobile device”), is configured to operate.

The computer system 14 may be a desktop or laptop PC, which isconfigured to communicate to the WAN 12, the Internet for example. PCs,such as computer system 14, normally access the Internet through anInternet Service Provider (ISP), Application Service Provider (ASP) orthe like.

The corporate LAN 18 is an example of a typical working environment, inwhich multiple computers 28 are connected in a network. It is normallylocated behind a security firewall 24. Within the corporate LAN 30, amessage server 26, operating on a computer behind the firewall 24, actsas the primary interface for the corporation to exchange messages bothwithin the LAN 18, and with other external messaging clients via the WAN12. Known message servers include, for example, Microsoft™ ExchangeServer and Lotus Domino™. These servers are often used in conjunctionwith Internet mail routers to route and deliver mail. The message server26 may also provide additional functionality, such as dynamic databasestorage for data like calendars, todo lists, task lists, e-mail anddocumentation. Although only a message server 26 is shown in the LAN 18,those skilled in the art will appreciate that a LAN may include othertypes of servers supporting resources that are shared between thenetworked computer systems 28. The message server 26 and electronicmessaging are described for illustrative purposes only. Owner controlsystems and methods are applicable to a wide range of electronicdevices, and are in no way limited to electronic devices with messagingcapabilities

The message server 26 provides messaging capabilities to networkedcomputer systems 28 coupled to the LAN 18. A typical LAN 18 includesmultiple computer systems 28, each of which implements a messagingclient, such as Microsoft Outlook™, Lotus Notes™, etc. Within the LAN18, messages are received by the message server 26, distributed to theappropriate mailboxes for user accounts addressed in the receivedmessage, and are then accessed by a user through a messaging clientoperating on a computer system 28.

The wireless gateway 16 provides an interface to a wireless network 20,through which messages may be exchanged with a mobile device 22. Themobile device 22 may, for example, be a data communication device, avoice communication device, a dual-mode communication device such asmany modern cellular telephones having both data and voicecommunications functionality, a multiple-mode device capable of voice,data and other types of communications, a personal digital assistant(PDA) enabled for wireless communications, or a laptop or desktopcomputer system with a wireless modem. An exemplary mobile device isdescribed in further detail below.

Such functions as addressing of the mobile device 22, encoding orotherwise transforming messages for wireless transmission, and any otherinterface functions may be performed by the wireless gateway 16. Thewireless gateway 16 may be configured to operate with more than onewireless network 20, in which case the wireless gateway 16 may alsodetermine a most likely network for locating a given mobile device 22and possibly track mobile devices as users roam between countries ornetworks.

Any computer system with access to the WAN 12 may exchange messages withthe mobile device 22 through the wireless network gateway 16.Alternatively, private wireless network gateways such as wirelessVirtual Private Network (VPN) routers could also be implemented toprovide a private interface to a wireless network. For example, awireless VPN implemented in the LAN 18 may provide a private interfacefrom the LAN 18 to one or more mobile devices such as 22 through thewireless network 20. Such a private interface to a mobile device 22 viathe wireless network gateway 16 and/or the wireless network 20 may alsoeffectively be extended to entities outside the LAN 18 by providing amessage forwarding or redirection system that operates with the messageserver 26. Such a message redirection system is disclosed in U.S. Pat.No. 6,219,694, which is hereby incorporated into this application byreference. In this type of system, incoming messages received by themessage server 26 and addressed to a user of a mobile device 22 are sentthrough the wireless network interface, either a wireless VPN router,wireless gateway 16 or other interface, for example, to the wirelessnetwork 20 and to the user's mobile device 22. Another alternateinterface to a user's mailbox on a message server 26 may be a WirelessApplication Protocol (WAP) gateway. Through a WAP gateway, a list ofmessages in a user's mailbox on the message server 26, and possibly eachmessage or a portion of each message, may be sent to the mobile device22.

A wireless network 20 normally delivers messages to and fromcommunication devices such as the mobile device 22 via RF transmissionsbetween base stations and devices. The wireless network 20 may, forexample, be a data-centric wireless network, a voice-centric wirelessnetwork, or a dual-mode network that can support both voice and datacommunications over the same infrastructure. Recently developed networksinclude Code Division Multiple Access (CDMA) networks, Groupe SpecialMobile or the Global System for Mobile Communications (GSM) and GeneralPacket Radio Service (GPRS) networks, and third-generation (3G) networkslike Enhanced Data rates for Global Evolution (EDGE) and UniversalMobile Telecommunications Systems (UMTS), which are currently underdevelopment. GPRS is a data overlay on top of the existing GSM wirelessnetwork, which is used operating in virtually every country in Europe.Some older examples of data-centric networks include, but are notlimited to, the Mobitex™ Radio Network (“Mobitex”), and the DataTAC™Radio Network (“DataTAC”). Examples of known voice-centric data networksinclude Personal Communication Systems (PCS) networks like GSM and TimeDivision Multiple Access (TDMA) systems that have been available inNorth America and world-wide for several years.

In the system 10, a company which owns the corporate LAN 18 may providea computer system 28 and a mobile device 22 to an employee. Stakeholdersin this example include the user of the mobile device 22, the companywhich owns the corporate LAN 18, and a carrier which operates thewireless network 20. As described above, each of these stakeholders mayhave an interest in controlling the mobile device 22 or certainresources or assets resident on the mobile device 22.

FIG. 2 is a block diagram of an exemplary wireless mobile communicationdevice in which a system and method for secure control may beimplemented. It should be apparent to those skilled in the art that onlythe components involved in a secure control system are shown in FIG. 2.The mobile device 30 will typically include further components,depending upon the type and functionality of the mobile device 30.

As shown in FIG. 2, a mobile device 30 comprises a memory 32, a domaincontroller 40, a wireless transceiver 48, a user interface (UI) 46, andan interface or connector 50. The memory 32 includes a key store 31, asoftware applications store 33 configured to store softwareapplications, a message store 34 for storing electronic messages, acontacts store 35 for storing contact information, a domain policy store36, a persistent data store 37, a communication “pipes” table 38, and aproperties store 39. These stores are illustrative of the types ofinformation stores that may be provided in the memory 32. Otherinformation stores may also be provided instead of or in addition tothose shown in FIG. 2.

The memory 32 is a writeable store such as a RAM into which other devicecomponents may write data. Within the memory 32, the key store 31 storescryptographic keys which may be used by the domain controller toimplement domain policies. The software applications store 33 includessoftware applications that have been installed on the mobile device 30,and may include, for example, an electronic messaging softwareapplication, a personal information management (PIM) softwareapplication, games, as well as other software applications. The messagestore 34 stores electronic messages associated with one or moremessaging software applications or services for which the mobile device30 has been enabled. The contacts store 35 also stores informationnormally associated with such messaging software applications andservices, including contact names, telephone and fax numbers, emailaddresses, mailing addresses, and the like. In the domain policy store36, domain membership control policies (“domain policies”), whichspecify the criteria used to determine into which domain a softwareapplication, property, or other information should be placed, arestored. Persistent data, or data which survives the termination of asoftware application which created it, is stored in the persistent store37. Communication pipes, described in further detail below, are mobiledevice communication assets and are listed in the communication pipestable 38. As will also be described below, the communication pipes table38 may also include or reference an application programming interface(API) 41 through which data may be sent to and received from acommunication pipe. Properties represent configuration data, and arestored in the properties store 39. Other data associated with the mobiledevice 30 or software applications installed on the mobile device 30 maybe stored in the data stores shown in FIG. 2, in further data stores inthe memory 32 but not shown in FIG. 2, or possibly in a separate memorycomponent on the mobile device 30.

The wireless transceiver 48 enables the mobile device 30 forcommunications via a wireless network, as described above in conjunctionwith FIG. 1. The mobile device 30 is also enabled for communicationswith a similarly-equipped PC or other device, including another mobiledevice, via the interface/connector 50. In FIG. 2, the domain controller40 is coupled to the memory 32, the wireless transceiver 48, the UI 46,and the interface/connector 50. As will be described in further detailbelow, access to such mobile device assets or resources is controlled bythe domain controller 40. The domain controller 40 will likely beimplemented most often as a software module or operating system that isexecuted by a mobile device processor (not shown). For example, wherethe mobile device 30 is a Java™-enabled device including a Java VirtualMachine (JVM) as its operating system, functionality of the domaincontroller 40 may be incorporated within the JVM or implemented as asoftware component that is executed by the JVM. Domain control at theoperating system level provides more streamlined and reliable domainsecurity than domain control at a software application level.

The UI 46 may include such UI components as a keyboard or keypad, adisplay, or other components which may accept inputs from or provideoutputs to a user of the mobile device 30. Although shown as a singleblock in FIG. 2, it should be apparent that a mobile device 30 typicallyincludes more than one UI, and the UI 46 is therefore intended torepresent one or more user interfaces.

The interface/connector 50 enables information transfer between themobile device 30 and a PC or another device via a communication linkestablished between the interface/connector 50 and a compatibleinterface or connector in the PC or other device. Theinterface/connector 50 could be any of a plurality of data transfercomponents, including, for example, an optical data transfer interfacesuch as an Infrared Data Association (IrDA) port, some other short-rangewireless communications interface, or a wired interface such as serialor Universal Serial Bus (USB) port and connection. Known short-rangewireless communications interfaces include, for example, “Bluetooth”modules and 802.11 modules according to the Bluetooth or 802.11specifications, respectively. It will be apparent to those skilled inthe art that Bluetooth and 802.11 denote sets of specifications,available from the Institute of Electrical and Electronics Engineers(IEEE), relating to wireless LANs and wireless personal area networks,respectively. Since communications between the mobile device 30 andother systems or devices via the interface/connector 50 need notnecessarily be via a physical connection, references to connecting amobile device to a PC or other device or system includes establishingcommunications through either physical connections or wireless transferschemes. Thus, the mobile device 30 could be connected to a PC, forexample, by placing the mobile device 30 in a mobile device cradleconnected to a serial port on the PC, by positioning the mobile device30 such that an optical port thereof is in a line of sight of a similarport of the PC, or by physically connecting or arranging the mobiledevice 30 and PC in some other manner so that data may be exchanged. Theparticular operations involved in establishing communications between amobile device and another system or device will be dependent upon thetypes of interfaces and/or connectors available in both the mobiledevice and the other system or device.

As described above, multiple stakeholders may have interests incontrolling mobile device assets or resources. In the mobile device 30,assets or resources include the wireless transceiver 48, UI 46,interface/connector 50, processor 40, and any of the stores orinformation in the memory 32. Some of these assets, such as the UI 46,might be usable by any software application or system on the mobiledevice 30, whereas one or more of the stakeholders may wish to exertstighter control over other assets, including the wireless transceiver48, interface/connector 50, and information stored in the memory 32, forexample.

In order to provide multiple-stakeholder secure control of the mobiledevice 30, assets may be assigned to domains, as shown in the stores inthe memory 32. The key store 31 includes cryptographic keys for domainsB and C. The software applications store 33, domain policy store 36,persistent data store 37, and communication pipes table 38 respectivelyinclude software applications, domain policies, persistent data, andcommunication pipes associated with domains A, B and C. The messagestore 34 and contacts store 35 include messages and contacts associatedwith domains B and C. In this example, only domains B and C haveassociated messaging software applications or services which use themessage store 34 and contacts store 35. Domain C includes acommunication pipe, but not for the purposes of electronic messaging inthis example. It is also possible that not all domains on a mobiledevice include a communication pipe. This may occur, for example, when adomain includes only software applications which provide local mobiledevice functions which do not require communications to or from themobile device.

A domain is a collection of objects that share a common level of trust,and can be owned and controlled by a mobile device stakeholder, such asa mobile device user, a mobile device owner, a carrier or a serviceprovider. Placing an object in a domain means that the object istrusted, and that its use can be restricted to other domain members.Each domain has a domain policy that controls which objects can becomemembers of a domain, as described in further detail below. By creatingdomains and assigning one or more domains on the mobile device to eachstakeholder, all stakeholders may maintain some level of control overmobile device assets that are part of the stakeholder's domain ordomains. The domain controller 40 manages each domain on the mobiledevice 30 and maintains control over access to domain assets orresources to ensure that trust requirements are satisfied before suchaccess is granted.

For example, most mobile devices may be purchased from any of a numberof retailers. Once purchased, a mobile device user can preferablyexecute a pre-installed software application that allows the user toenter credit card and other billing information that is used toprovision wireless network communication services. Those skilled in theart will appreciate that initial provisioning of such services on a newdevice may instead involve interactions with a carrier or serviceprovider customer service representative via a telephone or Internet webpage. The billing information is sent to a wireless carrier billingserver, which verifies the billing information and send a registrationmessage to the mobile device. The registration message is processed atthe mobile device to establish carrier domain on the mobile device.

The carrier domain may include such assets as a browser that can be usedto access Internet information and services via the carrier's wirelesscommunication network. The user may then use the browser in the carrierdomain to subscribe to a chat service, download the required softwareapplication from the Internet, and place the downloaded softwareapplication into the carrier domain. Other domain services, such as adomain backup frequency, for example, which specifies how often domaindata should be backed up, may also be configured by the user for thecarrier domain. Domain backup generally involves the transfer of domaindata, possibly including software applications, properties, andpersistent data to an external system. Such a backup operation allows adevice user, owner, or other stakeholder to restore a domain in theevent that the domain becomes corrupted, for example. Although the usermay configure some settings for the carrier domain on the mobile device,the carrier maintains ultimate control over the carrier domain, asdescribed in further detail below.

The user may also install other software applications and provisionfurther services using the mobile device. An electronic messagingservice which supports message exchange between the mobile device and apersonal email or other messaging account is one service that may be ofinterest to a mobile device user. A PC software application component ofsuch a service, when installed on a PC configured to access the personalmessaging account, establishes a user domain on the mobile device if onehas not already been established. Any mobile device softwareapplications required to use the service are then downloaded andinstalled on the mobile device, and placed in the user domain. Such aservice might also synchronize stored messages, contacts and possiblyfurther data associated with the personal messaging account between thePC and the mobile device, creating messages, contacts, and data in theuser domain. Since the electronic messaging service, and thus the userdomain, have access to a communication medium through which messages areexchanged with the PC, the user domain might also support Internetbrowsing. Using the web browser, the user may then download and installother software applications to the user domain. Where the softwareapplication is a birthday reminder program, for example, this programmay access all of the contacts that lie in the user domain and createreminders for their birthdays. The user domain may also haveuser-configurable settings, such as a domain backup frequency.

Where the user wishes to use the mobile device for work purposes aswell, he or she may send a message, an email for example, to the ITdepartment of his or her employer. The email includes the type of themobile device and its network address. The IT department then sends acreate domain message to the mobile device. When the create domainmessage is received at the mobile device, the user may first beprompted, using a UI 46 (FIG. 2), to accept this new domain. The newemployer domain is then created. Having created the employer domain onthe device, the IT department uploads such information as the companydirectory and a Customer Relationship Management (CRM) softwareapplication to the device. As described above for the carrier andpersonal domains, the employer domain may include settings which controlbehaviour and characteristics of the domain, such as domain backupfrequency. It is contemplated, however, that at least the employerdomain may be tightly controlled, such that employer domainconfiguration is established by the employer.

The introduction of domains in this example has some important mobiledevice control and security benefits. For example, the birthday reminderprogram in the user domain cannot access the company directory in theemployer domain, even though they are both stored on the same mobiledevice. Also, synchronization of the user domain data, such as personalcontacts, between the mobile device and a user's PC is accomplishedthrough a user domain communication pipe, associated with the personalmessaging service, so no corporate data from the employer domain isbacked up to the user's PC when the user domain is backed up. Similarly,any synchronization or backup of the employer domain data is performedthrough the employer domain communication pipe, so that the user'spersonal contacts are not copied to the corporate server.

In addition, none of the software applications in the carrier domain orthe user domain can access the communication pipe in the employerdomain. Only software applications in the employer domain can accesscorporate data which normally resides behind a security firewall in theemployer's corporate network. This prevents “Trojan horse” type softwareapplications from compromising the employer's network security. Theemployer IT department prevents the user from installing softwareapplications in the employer domain, as described in further detailbelow. The user can still install software applications in the userdomain, but they are not trusted by the employer.

The carrier can disable or upgrade software applications in the carrierdomain, but cannot effect software applications in the other domains.The carrier may, of course, prevent traffic from the mobile device ontheir communication network, but any mobile device could be enabled foroperation in multiple different communication networks operated bydifferent carriers.

Super user software applications provided by the mobile devicemanufacturer, for example, or some other source trusted by all domains,are members of multiple domains and thus present a unified view of dataacross multiple domains. This is useful in such software applications asan Address Book software application used to view and manage a contactsstore on a mobile device. Such super user software applications haveaccess to multiple domains, but also preferably respect the security ofeach domain. For example, a synchronization software application mightaccess all data but only backs up domain data through the appropriatedomain pipe. In order to avoid duplication of super user softwareapplication code on a mobile device, super user software applicationsmay be outside the domains to which they have access, and effectivelyassume domain membership from time to time, as required. Super usersoftware applications may therefore reside in a particular super userdomain, or possibly in a part of a software applications store that isnot associated with any particular domain.

The mobile device 30 (FIG. 2) implies a segregation of the variousstores in the memory 32 into different domain storage areas. However, itshould be appreciated that implementation of domains on a mobile devicemay be much more flexible than would be apparent from FIG. 2. Forexample, entries in any of the stores in the memory 32 need not beordered by domain. The software applications store 33 may include afirst software application in domain A, followed by another softwareapplication in domain C, and then a third software application which isalso in domain A. Even though the domain A software applications in thisexample do not occupy contiguous locations in the software applicationsstore 33, they are nonetheless associated with domain A.

FIG. 3 is a block diagram illustrating multiple domains on a wirelessmobile communication device. FIG. 2 shows domains from the perspectiveof physical device components, whereas FIG. 3 illustrates the practicaleffect of domains on mobile device assets. Therefore, the actual mobiledevice may be the same in FIGS. 2 and 3, although domain-based securecontrol of a mobile device will become more apparent from FIG. 3 and thefollowing description thereof.

The mobile device 52 in FIG. 3 includes an employer domain 54, a carrierdomain 62, and a user domain 64, each including software applications, acommunication pipe, and properties. The employer domain 54 and the userdomain 64 also include contacts and messages. The employer domain 54 andthe user domain 64 are respectively secured using the employer key 56and a user key 66, as will be described in further detail below. As willbe apparent from a comparison of FIGS. 2 and 3, the carrier domain 62,the employer domain 54, and the user domain 64 are similar to thedomains A, B and C, respectively, in FIG. 2. A default domain 58, whichcontains software applications and properties, and a properties domain68, which includes at least some of the properties stored in theproperties store 39 (FIG. 2), are also shown in FIG. 3.

Placing a software application in a domain gives it access to domainassets, most notably the domain communication pipe(s) and domain datasuch as persistent data and properties. In the employer domain 54, forexample, the CRM software application and the corporate messagingsoftware application have access to the corporate communication pipe,data such as corporate contacts and messages associated with a corporatemessaging account, and properties in the employer domain 54. Librarieswithin a domain are similarly accessible only from software applicationsin that domain.

Some software applications may be members of more than one domain. Thisgrants the software application access to data in multiple domains. InFIG. 3, both the employer domain 54 and the user domain 64 include amessaging software application. In this case, it is desirable to have asingle super user messaging software application that is a member of orhas access to both domains. However, the owners of both domains wouldhave to trust such a software application. Since the user of the mobiledevice has control over the user domain 64, a software applicationtrusted by another domain could fairly easily be granted access to theuser domain 64 by the user. When other domains than the user domain 64are involved, each domain owner has to trust a super user softwareapplication and grant access to such a software application to itsrespective domain.

Software application provisioning policy is preferably set on a perdomain basis, so that the domain owner can control which softwareapplications can be loaded into a domain. There are several methods ofcontrolling/assigning a software application to a domain. These arediscussed in further detail below.

A communication pipe is a means of communication between the mobiledevice and some external entity. A particular physical transport layer,such as Universal Serial Bus (USB), Bluetooth™, a serial port, 802.11and GPRS, can represent several logical communication pipes depending onthe gateway at the other end. For example, a GPRS radio can be used tocommunicate with both the carrier WAP gateway in the carrier domain 62,as well as a corporate gateway through the corporate communication pipein the employer domain 54. In this case, both the WAP gateway and thecorporate communication pipe represent separate communication pipes eventhough they use the same physical transport. One reason for thisseparation is that even though the same physical transport is used, thegateways are controlled by separate stakeholders.

Placing a communication pipe in a domain means that the domain ownertrusts that communication pipe. This is usually due to their control ofthe gateway or of the encryption keys that are used for communicationsover the communication pipe. In the case of the corporate communicationpipe, the communication pipe often includes a gateway through acorporate security firewall, such that access to the communication piperepresents a possible avenue of attack against a corporateinfrastructure. By placing the communication pipe inside a domain thatthey control, a corporate entity such as an employer restricts access tothe communication pipe and reduce the likelihood of attack.

As described above, any data that survives the termination of thesoftware application that created it is said to be persistent. In a moretraditional computer architecture, persistent data is written to a diskor database. Information in main memory is normally not persistent anddisappears when the software application exits, gracefully or otherwise,unless the software application takes explicit action to preserve thedata by writing it to a persistent store. Like most computers, mobiledevices have persistent and non-persistent storage. Persistent data isoften shared between software applications. Such sharing of data orsoftware application integration leads to useful and convenient featuresbut also introduces the possibility of data theft or corruption byunscrupulous software applications.

Domains allow the benefits of software application integration whilemitigating the risk to important data. By default, all persistent datacreated by a software application is placed in the same domain as thesoftware application. Only software applications in the same domain canaccess this persistent data. This allows the domain owner to ensure thatonly trusted software applications can access persistent data. Untrustedsoftware applications can still be loaded onto a mobile device withoutcompromising data integrity or security.

Properties are persistent data that represent configuration informationthat is either global, domain or software application specific. Unlikemost persistent data, properties allow a finer grain of access control.For example, it is possible to define a property that can be read by asoftware application but not modified. Properties can be placed in adomain and used to store user configuration or to set policies.

There may be several ways to add, modify, store, backup and restoreconfiguration data on a mobile device. In general, known configurationdata handling schemes relate to configuration data that is global to themobile device. Handling of configuration data on a per application basisis normally left up to the software application. However, a system leveldomain-based mechanism for handling software application configurationdata is desirable, for example, to place information about a softwareapplication in a secure location so that it can be used to define domainprovisioning policy. When configuration data is removed from the controlof the software application, the software application need not betrusted to set its own provisioning policy or manage its own applicationlifecycle.

As well as supporting software application provisioning, propertiesprovide a consistent set of software application configuration servicesto the software application developer. These software applicationconfiguration services include automatic backup and restoring ofproperties, automatic generation of a user interface for editingproperties, programmatic access to properties, a secure method ofexchanging properties additions or changes over the air from a mobiledevice, and a secure and tamperproof offline properties storagemechanism. Also, by defining properties at a global scope, propertiesmay be used to control configuration of a mobile device, not justsoftware applications on such a device.

Properties are named, typed data. They are akin to resources except thatthey are meant to be edited, whereas software application resources areusually defined when a software application is created and are notnormally changed. The name is an identifier that a software applicationcan use to refer to a property, and the type indicates a type of data ofthe property. Properties may also have a description, separate from thename. Separating the description from the name allows a propertiesediting to be internationalized without recompiling a softwareapplication.

The following property identifies a server with which a softwareapplication interacts:

Name: Server

Type: String

Value: http://sap.server.net/crm

Description: CRM Server.

This property might be used by a CRM software application on a mobiledevice that accesses data on a corporate server. The CRM softwareapplication is loaded in the employer domain 54 in FIG. 3. The serverproperty, required by the CRM software application, is also placed orcreated in the employer domain 54.

Properties preferably have access control. Not all properties can beread or modified by all software applications or stakeholders on amobile device. For example, the CRM software application is able to readthe name of the CRM server in the value field of the server property,but cannot modify it. Additionally, the ability to modify the server URLmay be reserved for the employer or corporate IT department. This isparticularly important when application properties are tied to systemresources. For example, if a mobile device security firewall uses anapplication property to allow or deny access to a corporate gatewaythrough the corporate communication pipe, then it would be important toprevent the software application from modifying this property. In thiscase, the software application cannot generate a user interface to allowediting this property, since it cannot modify the property. For thisreason, it is important to have a trusted application generate the userinterface for editing application properties. This trusted softwareapplication or Property Editor ensures that properties are properlylabelled, to prevent a user being mislead into modifying a property, andthat access control rules are enforced. Each property may have accesscontrol rules for each software application, as well as for each of thestakeholders on a mobile device. Since properties may be included inevery domain on a mobile device, a Property Editor is preferablyimplemented as a super user software application and thereby grantedaccess to the properties in multiple domains.

For example, the following property allows a software application toread but not modify or write to the property. A user or a domain is ableto both read and write to the property. Global rights are normallyassociated with a mobile device owner, which is not necessarily theuser, such as when the mobile device was provided to a user by anemployer. In this example, global rights include reading, but notwriting to, the property.

Name: HTTPAccess

Type: Boolean

Value: false

Description: Allow HTTP Access

Application: +read, −write

User: +read, +write

Domain: +read, +write

Global: +read, −write

Properties are preferably defined within a scope. Valid scopes, as shownin the properties store 39 in FIG. 2, may include global, domain andapplication. When a software application requests a list of properties,it gets all readable global properties, all readable properties in thesoftware application's domain, assuming the software application is amember of a domain, and all readable application properties for thesoftware application. In general, any readable properties which mayaffect the software application are provided in such a list. Theproperties placed within a domain may include application properties forthe software applications within the domain, as well as domainproperties. Global properties are placed in a separate properties domain68, which is preferably accessible to all mobile device softwareapplications, regardless of the domain in which each softwareapplication exists.

Access rules may also be applied to control the creation of newproperties of any particular scope. For example, the followingdefinition of global scope indicates that global properties may becreated by a user but not a software application:

Scope: Global

Application: −create

User: +create.

Domain scope properties for a particular domain may be defined, forexample, as:

Scope: Domain

Name: Employer

Application: +create

User: −create,

which means that software applications in the employer domain can createnew properties in that domain. A user cannot create new employer domainproperties in this example.

Software applications have programmatic access to read properties, andpossibly to modify and create properties. New properties can be createdin any of the software application's scopes, subject to scope accessrules. By default, new properties created by a software applicationpreferably have application scope.

As described above, a trusted software application, a Property Editor,generates a user interface for editing properties. Since softwareapplications may be able to modify and create properties, there shouldbe a way to programmatically invoke the Property Editor. For example,each software application may have a menu item called “Options” that canbe selected to invoke the Property Editor. When invoked from within asoftware application, the property editor does not display propertiesthat cannot be read by the software application. Properties that cannotbe modified by the software application are displayed in a read onlymode.

The Property Editor may group properties into multiple pages based onthe scope of the properties, for example, to reduce clutter. It may benecessary to allow the software application to define property groups asa hint to the Property Editor in the case where there are too manyproperties to fit on a single page.

Like other domain data, properties can preferably be backed up andrestored through one or more communication pipes, such as through aserial port or over the air. In reference to FIG. 2, backup and restoreoperations may be performed using the wireless transceiver 48 or theinterface/connector 50.

Backup through an interface or connector such as a serial port may beinitiated by a PC or other device with which a mobile devicecommunicates. All application properties may be backed up by default, sothat no serialization code is needed in the software applications. Aswell, any property data, and other domain data, that is stored to a diskmay be digitally signed and encrypted before being sent to the mobiledevice. This prevents tampering with the property data as a way tocircumvent the access control mechanisms.

Over the air backup and restore may be initiated either by a mobiledevice or by a remote server or system. Mobile device-initiated backupand restore are important for transports that do not support sendingdata to a device without first requesting such data. For example, if thedevice can only access a remote network through a WAP gateway, the userinitiates a backup of the device. This could be done by explicit useraction or by setting up a timer. Over the air restoration allowsrestoring properties to the last saved state. Again, this could beexplicitly initiated by the user as part of a device recovery task.

Server initiated backup and restore are forms of remote control of amobile device. Where the path to the device allows server-initiatedcommunication, the properties can be completely controlled from a remoteserver. Remote server actions may include, for example creating aproperty, modifying a property, deleting a property, getting a list ofproperties (globally or software application specific), and getting alist of software applications on a mobile device.

One purpose of domains is to define a restricted set of objects with acommon trust relationship. In general, no access to domain softwareapplications or data is granted to external entities, but all members ofa domain'are completely trusted. As described above, however, propertieshave a further level of access control. Although certain softwareapplications may span several domains, such a software application mayonly access a domain if it is trusted and has been granted access to thedomain by the owner of that domain.

The fundamental domain operations that are controlled are creating anddeleting domains, managing software applications (installing anddeleting), managing properties (creating, reading, modifying), andaccess to persistent data (creating, reading, modifying). A finergrained control can be achieved by introducing additional domains,subdomains or domain libraries.

A subdomain is a domain that lies within another domain. Members of asubdomain inherit all of the privileges of the parent domain. An exampleof a subdomain would be a human resources (HR) subdomain within theemployer domain 54. All software applications within the employer domain54, including those in the HR domain, can access the company directoryon a corporate network through the corporate data pipe, but onlysoftware applications in the HR domain may be able to access personalinformation on the corporate network. This allows different levels oftrust within a domain while sharing some common resources.

If a code library is a member of a domain, then it may be used to grantrestricted assess to domain data to software applications outside thedomain. This allows a domain owner to write their own access controlrules and use them to grant limited access to domain data through thelibrary. By default, domain libraries do not allow non-domain softwareapplications to make calls to domain libraries, but the domain ownercould relax this restriction on a per library basis. In this sense, adomain library that is accessible to software applications outside adomain is analogous to a domain controller in that it controls access todomain assets or resources associated with the library. Such a domainlibrary permits implementation of a finer granularity of domain accesscontrol or more complex access rules for a particular domain, or forspecific assets or resources within a domain.

In order for domain operations to be secure, domain policies control howobjects become members of a domain. There are several different possibledomain policies, each of which relies on a different trusted entity.

Perhaps the simplest domain policy is to allow objects to placethemselves into a domain. This relies on the unlikelihood of anuntrusted entity knowing about the domain. Information received at amobile device is placed into a domain indicated in the receivedinformation or possibly control information received with theinformation.

Another relatively simple scheme is to trust the communication pipe.This means that anything received over a domain communication pipe isplaced in that domain. This works well when the domain owner can controlthe pipe, as is the case with the carrier domain 62, for example.Referring to both FIG. 2 and FIG. 3, where domain A of FIG. 2corresponds to the carrier domain 62 in FIG. 3, this type of domainpolicy is specified as shown in the domain policy store 36. Wheninformation is received over the WAP gateway (pipe A), the domaincontroller 40 determines that it belongs to domain A, the carrier domain62, and places the information in that domain. The domain controller 40accesses the domain policy store 36 to determine whether the domain forthe communication pipe over which the information was received isconfigured for a trust the pipe domain policy. The domain controller 40may determine the domain for the communication pipe by consulting thecommunication pipe table 38. Where the API 41 is provided fortransferring data between the domain controller 40 and any communicationpipe in the communication pipe table 38, the communication pipe tablemay indicate to the domain controller 40 the domain to which thecommunication pipe belongs. It is also possible that receivedinformation may include an indicator of the domain in which it should beplaced. The domain controller 40 then accesses the domain policy store36 to determine the domain policy in effect for that domain.

A stronger method of domain security relies on cryptography. In a publickey system, each domain has an associated public and private key.Anything that is added to a domain must be digitally signed using thedomain private key. Only digital signatures generated using the domainprivate key can be verified using the domain public key, such as thekeys B and C, 56 and 66. This allows domain information to arrivethrough any pipe.

For example, an employer would normally want to ensure that the creationand control of the employer domain 54 is secure. A secure connection ispreferably established between the mobile device 52 and the employersystem before a create domain message is sent to the mobile device 52. Asecure connection could be established through encryption of the createdomain message or other cryptographic techniques, or using a securecommunication protocol between the employer system and the mobile device52. Encryption may involve public key cryptographic operations, or“shared secret” type cryptography. Secure domain creation techniques mayalso be used by other stakeholders to securely create domains on themobile device.

In order to ensure that all information for the employer domain isauthentic, both when the employer domain is created and when softwareapplications or data are subsequently to be placed in the employerdomain, information destined for the employer domain is digitally signedusing a signature private key of the employer, and the mobile device 52then verifies the digital signature before it places the data andsoftware applications in the employer domain.

Digital signature schemes generally involve some sort of transformationof digitally signed information to provide for checking the integrity ofthe information and authentication of a source of the signedinformation. For example, according to one digital signature scheme, adigest of information to be digitally signed is first generated using anon-reversible digest algorithm or transformation. Known digestalgorithms include Secure Hashing Algorithm 1 (SHA-1) and Message-Digestalgorithm 5 (MD5). Other digest techniques that produce a unique digestfor each unique input may also be used. The digest is then furthertransformed using a signer's signature private key and a signaturealgorithm to generate a digital signature. In order to provide fordigital signature verification, signature algorithms are normallyreversible, but only when a signature public key corresponding to thesignature private key is used. If the signed information has beenchanged after it was signed, or the digital signature was generatedusing any key other than the signer's signature private key, thensignature verification using the signer's signature public key fails.

In the context of secure domain control on the mobile device 52, adomain owner digitally signs any information destined for a domain onthe mobile device 52 using a signature private key. At the mobile device52, the information is not placed in the domain unless the digitalsignature is verified using the domain owner's signature public key 56or 66 for the domain. Referring again to both FIGS. 2 and 3, andspecifically to the employer domain 54 (domain B), when digitally signedinformation is received by the mobile device 30, the domain controller40 determines the domain for which the information is destined. Thedomain controller 40 may determine the appropriate domain by accessingthe communication pipes table 38, or based on a domain indication eitherfrom the API 41 in the communication pipes table 38 or in the receivedinformation. Since cryptographic or “trust the key” domain policiesfacilitate receipt of data for a particular domain over other than thecommunication pipe(s) in that domain, a domain indication in receivedinformation may be particularly useful in conjunction with this type ofdomain policy. Once the appropriate domain has been identified, thedomain controller 40 then retrieves the corresponding key for thedomain, key B in this example, from the key store 31. The information isplaced in the domain where the digital signature is verified using thekey B. The received information may be discarded, or possibly placed inthe default domain 58 if the digital signature is not verified. Theoperations of the domain controller 40 are similar for other domainshaving a trust the key domain policy, such as the user domain 64 (domainC).

As those skilled in the art of public key cryptography will appreciate,where a public key is not stored on a mobile device, it is obtained froma public key repository if it is not available in the key store 31 whenrequired. It should also be appreciated that other cryptographic accesscontrol mechanisms are possible, using cryptographic challenges andresponses or shared secret keys, for example.

When digital signature verification for received software applicationsor data fails, or software applications or data have not been signed,the software applications or data may be placed in a default domain 58.The default domain 58 includes software applications and properties andpossibly allows access to unrestricted device assets or resources. Adefault domain such as 58 may also provide temporary storage of unsignedor improperly signed software applications and data. Any softwareapplications and data in the default domain 58 could then be placed intoa user-controlled domain at a later time. In order to prevent denial ofservice type attacks exploiting the default domain 58, resourcesavailable to the default domain 58 are preferably limited. By limitingthe amount of memory that objects in the default domain 58 may occupy,for example, inundating a mobile device with unsigned or improperlysigned information cannot deplete the amount of memory available toother domains on the mobile device to such a degree as to render themobile device or software applications in other domains inoperable.

As a further alternative domain policy, when a domain is created, it mayinclude an access list established by the domain owner that describesall allowable members. This works well with software applications, butbecomes complex where control of persistent data is required. A hybridscheme where data is verified by some other method might be appropriatehere.

If a domain owner trusts the holder of the device, or the holder of thedevice is the domain owner, then each new object could be placed in thedomain by some on-device user interface, dependent upon a prompt to theuser. According to this domain policy, when a software application orother domain data is received at a mobile device, the user eitheraccepts the software application or data and places it in a domain orrejects the software application or data.

It may make sense to use different security techniques for differenttypes of objects. For example, domain creation may be controlledcryptographically. However, once a domain is established, it may trustthe domain pipe for further domain changes. Different domains might alsouse different security measures. Since the user domain 64 is controlledby the user of the mobile device 52, the user may be prompted to acceptor reject software applications and data for the user domain 64, whereasthe employer domain 54 and the, carrier domain 62, as shown, use acryptographic domain policy and a trust the pipe domain policy,respectively.

In regard to creating new domains, different control mechanisms couldalso be applied. As described above, new domains could be created inresponse to requests from a stakeholder, possibly subject to acceptanceby the user. Domain creation could be further restricted by trusting themobile device manufacturer. The device manufacturer could set up domainswhen the mobile device is manufactured. When a particular component of amobile device is configured to store information, then that componentcould be manufactured with certain domains. This technique applies toGPRS mobile devices, for example, which require a Subscriber IdentityModule or SIM for operation. Domains could be configured on a SIM by aSIM manufacturer, owner or other stakeholder before the SIM is providedto a user.

FIG. 4 is a flow diagram showing a method for secure control of awireless mobile communication device. The method begins at step 70,where a request to perform an operation is received at the mobiledevice. The mobile device 30 (FIG. 2), for example, may receive such arequest through the wireless transceiver 48, from a UI 46, through theinterface/connector 50, or from a software application running on themobile device 30. A received request is then passed to a domaincontroller 40 (FIG. 2), which determines in which domain the assets orresources affected by the requested operation are located. Referringagain to FIG. 2, if the request is a memory access request by a softwareapplication to read record 1 in the persistent data store 37, then thedomain controller 40 determines that record 1 belongs to domain A. InFIG. 2, a domain identifier or indicator is stored with each record inthe persistent data store 37. Objects in other stores may similarlyinclude such a domain identifier to allow the domain controller todetermine the domain to which an object belongs. For domains withcryptographic or trust the key domain policies, digitally signed domaindata, which may include software applications, properties, persistentdata, or other information, that is, received by the mobile device 30may be stored in signed form. The domain controller 40 can then confirmthat an object is trusted by a particular domain by verifying thedigital signature stored with the object using the appropriatecryptographic key. The domain controller 40 may also be configured toestablish and maintain or at least consult an access control list thatspecifies associations between domains and the objects that have beengranted access to the domains. Different domains on a mobile device mayalso use different schemes for indicating domain membership, providedthe domain controller on the mobile device is configured to handle suchdifferent schemes.

At step 74, the domain controller determines whether the requestedoperation is permitted. This determination involves determining thedomain from which the received request originated. As described above,each member of a domain is trusted and has access to assets within thatdomain. The requested operation is completed at step 76 where theoperation is permitted. In the above example of a request from asoftware application to read record 1, the read operation is completedwhere the requesting software application is in domain A, the samedomain as the record to be read. The domain controller 40 may determine,and possibly confirm, the domain from which a request originatessubstantially as described above in the context of determining thedomain to which an asset belongs. Where the operation is not permitted,the operation is denied at step 78, and error processing operations, ifany, are performed at step 80. Error processing operations at step 80may include, for example, returning an error or failure indication tothe requesting object and displaying an error message to a user of themobile device.

The determination at step 74 may include further or alternativeoperations beyond determining whether the received request originatedfrom the same domain as the domain assets affected by the requestedoperation. A “same domain” determination represents but one example ofhow a trust relationship might be verified. In the case of a super usersoftware application, the software application might not belong to anyparticular domain. Therefore, instead of determining an originatingdomain, a domain controller determines whether the super user softwareapplication is trusted and has been granted access to the affecteddomain assets by the domain owner. Also, as described above, propertiesmay have additional access rules. As such, when a requested operationaffects properties, further criteria may be applied at step 74 todetermine whether the operation is permitted. Domain policies may alsobe examined by a domain controller at step 74, where the receivedrequest relates to new domain data that is to be placed into an existingdomain. If the request is a create domain message, then step 74 mayinvolve interaction with a user to accept or reject a new domain.

Although the method in FIG. 4 has been described primarily in thecontext of a read operation as an example of a controlled operation, itshould be apparent that other operations may be similarly controlled.Domain assets thereby remain protected from objects in other domains,and may be accessed only by trusted objects in the same domain or superuser software applications that are trusted by multiple domains. Whendata is to be sent using a particular domain's communication pipe, forexample, the domain controller first determines whether an object ordomain attempting to send the data has been granted access to thecommunication pipe by the domain owner, such as by determining whetherthe sending object or domain is in the same domain as the communicationpipe. The domain controller 40 accesses the communication pipes table 38to determine to which domain a communication pipe belongs, and then senddata to the communication pipe via the API 41 where the sending objectin that same domain or has been granted access to the communication pipein that domain by the domain owner.

The method shown in FIG. 4 relates to control of a mobile device basedon domains. Global, domain, or application properties are used toestablish further controls, as described above. The processing of arequest for an operation may therefore also or instead involve checkingsuch properties to determine if an operation is permitted. Although asoftware application might have access to a communication pipe in adomain, an application property might indicate that the softwareapplication has expired, or a global property may specify that thesoftware application cannot send data from the mobile device. Althoughproperties are included in the domains shown in FIGS. 2 and 3 and affectoperations associated with domains, property-based control may beimplemented separately from domain-based control. For example, where anoperation is to be performed by a software application, the applicationproperties associated with software application may first be accessed todetermine whether the operation is permitted for the softwareapplication. A request for the operation is then sent to a domaincontroller only if the application properties permit the operation bythe software application. In this example, application propertiesprovide a first level of control, and domains provide a further level ofcontrol. It should be appreciated, however, that either property-basedcontrol or domain-based control may be implemented on a mobile device.Although these control schemes complement each other, they can insteadbe independent.

Having described domains, properties and related security mechanisms,domain- and property-based services and uses will now be described.

Since a domain describes a set of data and possibly a communicationpipe, the communication pipe is used to perform a backup operation on adomain. This involves sending all of the domain data, includingproperties and software applications, over the communication pipe to abackup system or server. Similarly, as part of a device recovery plan,the backup system or server is used to re-establish the domain on themobile device and restore all of the data. In this case, the domaindefines what should be backed up, as well as the trusted communicationpath to use. Domains that do not include a communication pipe may bebacked up through another available data pipe or transport that has notbeen assigned to a domain. Digital signing and encryption techniques,when used during backup and restore operations, ensure security andintegrity of domain data.

It is also possible to place objects from multiple domains into singlecontainer classes. When a software application requests an iterator onsuch a class, it enumerates only the elements in the proper domain.Super user software applications, such as an Address Book softwareapplication, should be able to request an iterator for a particulardomain. This makes it easy to write a software application where theuser requests a domain specific view on the data. For example, theAddress Book could be configured to display only contacts in theemployer domain 54.

Super user software applications that span domains also assume domainmembership for a finite period of time. This allows a super usersoftware application to act on the behalf of a domain without having toduplicate code that enforces domain access control. An example wherethis might be useful is in a data synchronization software application.When it is backing up a domain, such a software application assumesmembership in that domain. This allows the underlying operating systemto ensure that domain data is only written to the domain communicationpipe.

One of the primary uses for domains is to provide data security. Byplacing a software application in a domain, access to that softwareapplication's data is restricted to other software applications in thatdomain. Levels of security within a single organization can berepresented by multiple domains or by subdomains. Where the enforcementof domain policies is performed by a mobile device system such as a JVMand not a software application, bad programming on the part of thedeveloper is less likely to result in a security breach.

Domains are also useful in over the air software applicationprovisioning for mobile devices. Where each stakeholder is provided witha respective domain, software applications installed in one domain donot affect mobile device assets, software applications, or data in otherdomains. Thus, neither a carrier providing communication services to amobile device nor an employer as an owner of a mobile device need beconcerned that user software applications installed in a user domain onthe mobile device will affect carrier domain assets, softwareapplications or data or corporate assets, software applications or data.Software application provisioning may also include loading ofconfiguration data for a software application in the form of applicationproperties. Other aspects of software applications on a mobile deviceare also controllable using application properties. A domain owner, suchas a service provider, may specify that a software application may beexecuted only a specific number of times, only a specific number oftimes in a certain time period, or only a specific number of timesbefore service charges apply. By placing properties within domains, astakeholder maintains secure control over domain assets, includingsoftware applications in the domain.

Just as properties can be mapped to mobile device resource access suchas HTTP access and, phone access, for example, they can also be mappedto device state information, including information on available memoryand date and time of last mobile device reset. This allows remotequerying of the mobile device state. Such a query could be initiated bya device management server or be triggered by a timer on the mobiledevice. By querying these system-mapped properties, a server canremotely manage the mobile device. Some of these properties will belocal to a domain, such as a maximum number of recipients per message,and some will be global to the device, the minimum length of a password,for example.

FIG. 5 is a block diagram of an example wireless mobile communicationdevice. The mobile device 500 is preferably a two-way communicationdevice having at least voice and data communication capabilities. Themobile device 500 preferably has the capability to communicate withother computer systems on the Internet. Depending on the functionalityprovided by the mobile device, the mobile device may be referred to as adata messaging device, a two-way pager, a cellular telephone with datamessaging capabilities, a wireless Internet appliance, or a datacommunication device (with or without telephony capabilities). Asmentioned above, such devices are referred to generally herein simply asmobile devices.

The mobile device 500 includes a transceiver 511, a microprocessor 538,a display 522, Flash memory 524, RAM 526, auxiliary input/output (I/O)devices 528, a serial port 530, a keyboard 532, a speaker 534, amicrophone 536, a short-range wireless communications sub-system 540,and may also include other device sub-systems 542. The transceiver 511preferably includes transmit and receive antennas 516, 518, a receiver(Rx) 512, a transmitter (Tx) 514, one or more local oscillators (LOs)513, and a digital signal processor (DSP) 520. Within the Flash memory524, which may alternatively be another type of non-volatile store suchas a battery backed-up RAM, the mobile device 500 preferably includes aplurality of software modules 524A-524N that can be executed by themicroprocessor 538 (and/or the DSP 520), including a voice communicationmodule 524A, a data communication module 524B, and a plurality of otheroperational modules 524N for carrying out a plurality of otherfunctions.

The mobile device 500 is preferably a two-way communication devicehaving voice and data communication capabilities. Thus, for example, themobile device 500 may communicate over a voice network, such as any ofthe analog or digital cellular networks, and may also communicate over adata network. The voice and data networks are depicted in FIG. 5 by thecommunication tower 519. These voice and data networks may be separatecommunication networks using separate infrastructure, such as basestations, network controllers, etc., or they may be integrated into asingle wireless network. References to the network 519 should thereforebe interpreted as encompassing both a single voice and data network andseparate networks.

The communication subsystem 511 is used to communicate with the network519. The DSP 520 is used to send and receive communication signals toand from the transmitter 514 and receiver 512, and may also exchangecontrol information with the transmitter 514 and receiver 512. If thevoice and data communications occur at a single frequency, orclosely-spaced set of frequencies, then a single LO 513 may be used inconjunction with the transmitter 514 and receiver 512. Alternatively, ifdifferent frequencies are utilized for voice communications versus datacommunications, then a plurality of LOs 513 can be used to generate aplurality of frequencies corresponding to the network 519. Although twoantennas 516, 518 are depicted in FIG. 5, the mobile device 500 could beused with a single antenna structure. Information, which includes bothvoice and data information, is communicated to and from thecommunication module 511 via a link between the DSP 520 and themicroprocessor 538.

The detailed design of the communication subsystem 511, such asfrequency band, component selection, power level, etc., will bedependent upon the communication network 519 in which the mobile device500 is intended to operate. For example, a mobile device 500 intended tooperate in a North American market may include a communication subsystem511 designed to operate with the Mobitex or DataTAC mobile datacommunication networks and also designed to operated with any of avariety of voice communication networks, such as AMPS, TDMA, CDMA, PCS,etc., whereas a mobile device 500 intended for use in Europe may beconfigured to operate with the GPRS data communication network and theGSM voice communication network. Other types of data and voice networks,both separate and integrated, may also be utilized with the mobiledevice 500.

Depending upon the type of network 519, the access requirements for themobile device 500 may also vary. For example, in the Mobitex and DataTACdata networks, mobile devices are registered on the network using aunique identification number associated with each device. In GPRS datanetworks, however, network access is associated with a subscriber oruser of the mobile device 500. A GPRS device typically requires a SIM inorder to operate the mobile device 500 on a GPRS network. Local ornon-network communication functions (if any) may be operable, withoutthe SIM, but the mobile device 500 will be unable to carry out anyfunctions involving communications over the network 519, other than anylegally required operations, such as ‘911’ emergency calling. Asdescribed above, domains may be established on a SIM before it isprovided to a user, with further domains possibly being added to a SIMafter it has been installed in a mobile device. When a GPRS device alsoincludes a memory component, domains may exist on the memory componentand the SIM. Different types of domain control and domain policies couldbe implemented depending upon the location of a domain.

After any required network registration or activation procedures havebeen completed, the mobile device 500 may send and receive communicationsignals, preferably including both voice and data signals, over thenetwork 519. Signals received by the antenna 516 from the communicationnetwork 519 are routed to the receiver 512, which provides for signalamplification, frequency down conversion, filtering, channel selection,analog to digital conversion, etc. Analog to digital conversion of thereceived signal allows more complex communication functions, such asdigital demodulation and decoding to be performed using the DSP 520. Ina similar manner, signals to be transmitted to the network 519 areprocessed, including modulation and encoding, for example, by the DSP520 and are then provided to the transmitter 514 for digital to analogconversion, frequency up conversion, filtering, amplification andtransmission to the communication network 519 via the antenna 518.Although a single transceiver 511 is shown in FIG. 5 for both voice anddata communications, it is possible that the mobile device 500 mayinclude two distinct transceivers, such as a first transceiver fortransmitting and receiving voice signals, and a second transceiver fortransmitting and receiving data signals, or a first transceiverconfigured to operate within a first frequency band, and a secondtransceiver configured to operate within a second frequency band.

In addition to processing the communication signals, the DSP 520 mayalso provide for receiver and transmitter control. For example, the gainlevels applied to communication signals in the receiver 512 andtransmitter 514 may be adaptively controlled through automatic gaincontrol algorithms implemented in the DSP 520. Other transceiver controlalgorithms could also be implemented in the DSP 520 in order to providemore sophisticated control of the transceiver 511.

The microprocessor 538 preferably manages and controls the overalloperation of the mobile device 500. Many types of microprocessors ormicrocontrollers could be used here, or, alternatively, a single DSP 520could be used to carry out the functions of the microprocessor 538.Low-level communication functions, including at least data and voicecommunications, are performed through the DSP 520 in the transceiver511. Other, high-level communication software applications, such as avoice communication software application 524A, and a data communicationsoftware application 524B may be stored in the Flash memory 524 forexecution by the microprocessor 538. For example, the voicecommunication module 524A may provide a high-level user interfaceoperable to transmit and receive voice calls between the mobile device500 and a plurality of other voice devices via the network 519.Similarly, the data communication module 524B may provide a high-leveluser interface operable for sending and receiving data, such as e-mailmessages, files, organizer information, short text messages, etc.,between the mobile device 500 and a plurality of other data devices viathe network 519.

The microprocessor 538 also interacts with other device subsystems, suchas the display 522, Flash memory 524, random access memory (RAM) 526,auxiliary input/output (I/O) subsystems 528, serial port 530, keyboard532, speaker 534, microphone 536, a short-range communications subsystem540 and any other device subsystems generally designated as 542. Forexample, the modules 524A-N are executed by the microprocessor 538 andmay provide a high-level interface between a user of the mobile deviceand the mobile device. This interface typically includes a graphicalcomponent provided through the display 522, and an input/outputcomponent provided through the auxiliary I/O 528, keyboard 532, speaker534, or microphone 536. Such interfaces are designated generally as UI46 in FIG. 2.

Some of the subsystems shown in FIG. 5 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 532 and display522 may be used for both communication-related functions, such asentering a text message for transmission over a data communicationnetwork, and device-resident functions such as a calculator or task listor other PDA type functions.

Operating system software used by the microprocessor 538 is preferablystored in a persistent store such as Flash memory 524. In addition tothe operating system and communication modules 524A-N, the Flash memory524 may also include a file system for storing data. The Flash memory524 may also include data stores for application, domain and globalproperties. The operating system, specific device software applicationsor modules, or parts thereof, may be temporarily loaded into a volatilestore, such as RAM 526 for faster operation. Moreover, receivedcommunication signals may also be temporarily stored to RAM 526, beforepermanently writing them to a file system located in the Flash memory524. Although the device 500 includes a Flash memory 524 as anon-volatile store, it should be appreciated that Flash memoryrepresents one example of a non-volatile memory. Other memoryarrangements, such as battery backed-up RAM, for example, may be usedinstead of the Flash memory 524.

An exemplary software application module 524N that may be loaded ontothe mobile device 500 is a PIM software application providing PDAfunctionality, such as calendar events, appointments, and task items.This module 524N may also interact with the voice communication module524A for managing phone calls, voice mails, etc., and may also interactwith the data communication module 524B for managing e-mailcommunications and other data transmissions. Alternatively, all of thefunctionality of the voice communication module 524A and the datacommunication module 524B may be integrated into the PIM module.

The Flash memory 524 preferably provides a file system to facilitatestorage of PIM data items on the device. The PIM software applicationpreferably includes the ability to send and receive data items, eitherby itself, or in conjunction with the voice and data communicationmodules 524A, 524B, via the wireless network 519. The PIM data items arepreferably seamlessly integrated, synchronized and updated, via thewireless network 519, with a corresponding set of data items stored orassociated with a host computer system, thereby creating a mirroredsystem for data items associated with a particular user.

The mobile device 500 may also be manually synchronized with a hostsystem by placing the mobile device 500 in an interface cradle, whichcouples the serial port 530 of the mobile device 500 to the serial portof the host system. The serial port 530 may also be used to downloadother software application modules 524N, properties, and data to one ormore domains on the mobile device 500. This wired download path mayfurther be used to load an encryption key onto the mobile device 500 foruse in secure communications, which is a more secure method thanexchanging encryption information via the wireless network 519.

Additional software application modules 524N, properties and data mayalso be loaded to domains on the mobile device 500 through the network519, through an auxiliary I/O subsystem 528, through the short-rangecommunications subsystem 540, or through any other suitable subsystem542, and installed by a user in the Flash memory 524 or RAM 526. Suchflexibility in software application installation increases thefunctionality of the mobile device 500 and may provide enhancedon-device functions, communication-related functions, or both. Forexample, secure communication software applications may enableelectronic commerce functions and other such financial transactions tobe performed using the mobile device 500.

When the mobile device 500 is operating in a data communication mode, areceived signal, such as a text message or a web page download, will beprocessed by the transceiver 511 and provided to the microprocessor 538,which will preferably further process the received signal for output tothe display 522, or, alternatively, to an auxiliary I/O device 528. Auser of mobile device 500 may also compose data items, such as emailmessages, using the keyboard 532, which is preferably a completealphanumeric keyboard laid out in the QWERTY style, although otherstyles of complete alphanumeric keyboards such as the known DVORAK stylemay also be used. User input to the mobile device 500 is furtherenhanced with a plurality of auxiliary I/O devices 528, which mayinclude a thumbwheel input device, a touchpad, a variety of switches, arocker input switch, etc. The composed data items input by the user maythen be transmitted over the communication network 519 via thetransceiver 511. Where the data communication module 524B is in aparticular domain, received and composed data items would preferably bestored in that domain, and the composed data items would also be sentover the domain data pipe.

When the mobile device 500 is operating in a voice communication mode,the overall operation of the mobile device 500 is substantially similarto the data mode, except that received signals are preferably output tothe speaker 534, voice signals for transmission are generated by amicrophone 536, and a different domain data pipe and assets may be used.Alternative voice or audio I/O subsystems, such as a voice messagerecording subsystem, may also be implemented on the mobile device 500.Although voice or audio signal output is preferably accomplishedprimarily through the speaker 534, the display 522 may also be used toprovide an indication of the identity of a calling party, the durationof a voice call, or other voice call related information. For example,the microprocessor 538, in conjunction with the voice communicationmodule 524A and the operating system software, may detect the calleridentification information of an incoming voice call and display it onthe display 522.

A short-range communications subsystem 540 may also be included in themobile device 500. For example, the subsystem 540 may include aninfrared device and associated circuits and components, or a Bluetoothor 802.11 short-range wireless communication module to provide forcommunication with similarly-enabled systems and devices. Thus, ownerinformation insertion, owner control information insertion, and softwareapplication loading operations as described above may be enabled on themobile device 500 via the serial port 530 or other short-rangecommunications subsystem 540.

It will be appreciated that the above description relates to preferredembodiments by way of example only. Many variations on the systems andmethods described above will be obvious to those knowledgeable in thefield, and such obvious variations are within the scope of the inventionas described and claimed, whether or not expressly described.

INDUSTRIAL APPLICABILITY

The invention provides improved security for wireless mobilecommunication devices.

What is claimed as the invention is:
 1. A method for control ofresources of a mobile device, the method comprising: segregating themobile device into a plurality of domains including a first domaincontrolled by a first domain owner, and a second domain controlled by asecond domain owner, wherein the first domain owner is an employer, andthe second domain owner is an owner of the mobile device; receiving arequest to perform an operation, wherein the operation affects an assetof the mobile device; responsive to receiving the request: denying, by adomain controller, the request if the request originated from adifferent domain than the asset; and permitting, by the domaincontroller, the request if the request originated from the same domainas the asset.
 2. The method of claim 1, further comprising determining,by the domain controller, which of the domains the request originatedfrom using a cryptographic key from a key store; and determining, by thedomain controller, which of the domains the asset belongs to using thecryptographic key from the key store.
 3. The method of claim 1 furthercomprising: receiving information; and assigning the information to oneof the domains based upon a domain policy.
 4. The method of claim 3,wherein the domain policy specifies that information should beassociated with a domain based upon any one or more of the followingincluding any combination thereof: a source of the information, adigital signature of the information, an access list describing alloweddomain information, and an input from a user of the mobile device. 5.The method of claim 3, wherein the domain policy specifies thatinformation should be associated with a domain based upon an indicatorof a domain in the information.
 6. The method of claim 3, wherein thedomain policy specifies that information is associated with a domainbased upon a communication pipe over which the information was received.7. The method of claim 1 further comprising: determining whether theoperation is permitted based upon one or more properties stored in aproperty store; and denying the request when the operation is notpermitted based upon the one or more properties in the property store.8. The method of claim 7, wherein the one or more properties compriseany one or more of the following including any combination thereof: oneor more global properties, one or more domain properties, and one ormore application properties.
 9. The method of claim 1, wherein the assetcomprises at least one of: a communication pipe, persistent data, aproperty, a software application, a wireless transceiver, a userinterface, an interface/connector, a processor, a memory, or a datastore.
 10. The method of claim 9, wherein the persistent data includesany one or more of the following including any combination thereof:messages, contact information, calendar items, task items, configurationinformation, properties, records, and voice mails.
 11. The method ofclaim 1, wherein the request originates from at least one of: acommunication pipe, persistent data, a property, or a softwareapplication.
 12. The method of claim 1, wherein the plurality of domainsincludes a work domain and a personal domain.
 13. The method of claim 1,wherein the plurality of domains includes a carrier domain.
 14. Themethod of claim 1, wherein the domain controller is configured toprocess the request based upon input from the first domain owner and thesecond domain owner.
 15. A mobile device comprising: a memory comprisinga plurality of domains including a first domain controlled by a firstdomain owner, and a second domain controlled by a second domain owner,wherein the first domain owner is an employer, and the second domainowner is an owner of the mobile device; and a domain controllerconfigured to: receive a request to perform an operation, wherein theoperation affects an asset; deny the request if the request originatedfrom a different domain than the asset; and permit the request if therequest originated from the same domain as the asset.
 16. The method ofclaim 1, wherein the operation includes any one or more of the followingincluding any combination thereof: creating a domain, deleting a domain,managing a software application, installing a software application,deleting a software application, managing a property, creating aproperty, reading a property, modifying a property, creating data,reading data, modifying data, and accessing data.
 17. The method ofclaim 1, wherein the request is from any one or more of the followingincluding any combination thereof: an external entity, a devicemanagement server, a corporate entity, and an employer.
 18. The methodof claim 1, wherein the asset comprises a software application thatpresents a unified view of data across multiple domains.
 19. The methodof claim 1, wherein the mobile device includes an application havingaccess to multiple domains.
 20. The method of claim 1, wherein themobile device includes a messaging application having access to multipledomains.
 21. The method of claim 1, wherein the mobile device includesan address book application having access to multiple domains.
 22. Themethod of claim 1, wherein the plurality of domains includes a workdomain and a personal domain.
 23. The mobile device of claim 15, whereinthe domain controller is configured to process the request based uponinput from the first domain owner and the second domain owner.
 24. Themobile device of claim 15, wherein the domain controller is furtherconfigured to determine which of the domains the request originated frombased upon a digital signature.
 25. The mobile device of claim 15,wherein the domain controller is further configured to determine whichof the domains the request originated from based upon a communicationpipe where the request is received.
 26. The mobile device of claim 15,further comprising: a super user application configured to temporarilyassume membership of either the first domain based upon approval by thefirst domain owner or the second domain based upon approval by thesecond domain owner.
 27. The mobile device of claim 26, wherein thesuper user application is further configured to modify properties in thefirst domain and the second domain.
 28. The mobile device of claim 15,wherein the domain controller is further configured to deny the requestwhen the domain controller determines that the request violates aproperty mapped to the asset.
 29. The mobile device of claim 28, whereinthe property comprises any one or more of the following including anycombination thereof: one or more global properties, one or more domainproperties, and one or more application properties.
 30. The mobiledevice of claim 15, wherein the operation includes any one or more ofthe following including any combination thereof: creating a domain,deleting a domain, managing a software application, installing asoftware application, deleting a software application, managing aproperty, creating a property, reading a property, modifying a property,creating data, reading data, modifying data, or accessing data.
 31. Themobile device of claim 15, wherein the first domain comprises asubdomain, wherein the domain controller is further configured to permitrequests from the subdomain within the first domain.
 32. The mobiledevice of claim 15, wherein the asset includes at least one of: acommunication pipe, persistent data, a property, a software application,a wireless transceiver, a user interface, an interface, a connector, aprocessor, a memory, or a data store.
 33. The mobile device of claim 32,wherein the persistent data includes any one or more of the followingincluding any combination thereof: messages, contact information,calendar items, task items, configuration information, properties,records, and voice mails.
 34. The mobile device of claim 15, wherein therequest originates from at least one of: a communication pipe,persistent data, a property, or a software application.
 35. The mobiledevice of claim 15, wherein the domain controller is further configuredto execute error processing operations subsequent to denying therequest.
 36. The mobile device of claim 15, wherein the plurality ofdomains includes a work domain and a personal domain.
 37. The mobiledevice of claim 15, wherein the plurality of domains includes a carrierdomain.
 38. The mobile device of claim 15, further comprising: anapplication having access to multiple domains.
 39. The mobile device ofclaim 15, further comprising: a messaging application having access tomultiple domains.
 40. The mobile device of claim 15, further comprising:an address book application having access to multiple domains.
 41. Themobile device of claim 15, further comprising: an application configuredto provide a unified view of data across multiple domains.
 42. A methodfor control of resources of a mobile device, the method comprising:segregating the mobile device into a plurality of domains including afirst domain controlled by a first domain owner, and a second domaincontrolled by a second domain owner, wherein the first domain owner isan employer, and the second domain owner is an employee of the employer;receiving a request to perform an operation, wherein the operationaffects an asset of the mobile device; responsive to receiving therequest: denying, by a domain controller, the request if the requestoriginated from a different domain than the asset; and permitting, bythe domain controller, the request if the request originated from thesame domain as the asset.
 43. The method of claim 42, further comprisingdetermining, by the domain controller, which of the domains the requestoriginated from using a cryptographic key from a key store; anddetermining, by the domain controller, which of the domains the assetbelongs to using the cryptographic key from the key store.
 44. Themethod of claim 42 further comprising: receiving information; andassigning the information to one of the domains based upon a domainpolicy.
 45. The method of claim 44, wherein the domain policy specifiesthat information should be associated with a domain based upon any oneor more of the following including any combination thereof: a source ofthe information, a digital signature of the information, an access listdescribing allowed domain information, and an input from a user of themobile device.
 46. The method of claim 44, wherein the domain policyspecifies that information should be associated with a domain based uponan indicator of a domain in the information.
 47. The method of claim 44,wherein the domain policy specifies that information is associated witha domain based upon a communication pipe over which the information wasreceived.
 48. The method of claim 42 further comprising: determiningwhether the operation is permitted based upon one or more propertiesstored in a property store; and denying the request when the operationis not permitted based upon the one or more properties in the propertystore.
 49. The method of claim 48, wherein the one or more propertiescomprise any one or more of the following including any combinationthereof: one or more global properties, one or more domain properties,and one or more application properties.
 50. The method of claim 42,wherein the asset comprises at least one of: a communication pipe,persistent data, a property, a software application, a wirelesstransceiver, a user interface, an interface/connector, a processor, amemory, or a data store.
 51. The method of claim 50, wherein thepersistent data includes any one or more of the following including anycombination thereof: messages, contact information, calendar items, taskitems, configuration information, properties, records, and voice mails.52. The method of claim 42, wherein the request originates from at leastone of: a communication pipe, persistent data, a property, or a softwareapplication.
 53. The method of claim 42, wherein the plurality ofdomains includes a work domain and a personal domain.
 54. The method ofclaim 42, wherein the plurality of domains includes a carrier domain.55. The method of claim 42, wherein the domain controller is configuredto process the request based upon input from the first domain owner andthe second domain owner.
 56. The method of claim 42, wherein theoperation includes any one or more of the following including anycombination thereof: creating a domain, deleting a domain, managing asoftware application, installing a software application, deleting asoftware application, managing a property, creating a property, readinga property, modifying a property, creating data, reading data, modifyingdata, and accessing data.
 57. The method of claim 42, wherein therequest is from any one or more of the following including anycombination thereof: an external entity, a device management server, acorporate entity, and an employer.
 58. The method of claim 42, whereinthe asset comprises a software application that presents a unified viewof data across multiple domains.
 59. The method of claim 42, wherein themobile device includes an application having access to multiple domains.60. The method of claim 42, wherein the mobile device includes amessaging application having access to multiple domains.
 61. The methodof claim 42, wherein the mobile device includes an address bookapplication having access to multiple domains.
 62. The method of claim42, wherein the plurality of domains includes a work domain and apersonal domain.
 63. A mobile device comprising: a memory comprising aplurality of domains including a first domain controlled by a firstdomain owner, and a second domain controlled by a second domain owner,wherein the first domain owner is an employer, and the second domainowner is an employee of the employer; and a domain controller configuredto: receive a request to perform an operation, wherein the operationaffects an asset; deny the request if the request originated from adifferent domain than the asset; and permit the request if the requestoriginated from the same domain as the asset.
 64. The mobile device ofclaim 63, wherein the domain controller is further configured todetermine which of the domains the request originated from based upon adigital signature.
 65. The mobile device of claim 63, wherein the domaincontroller is further configured to determine which of the domains therequest originated from based upon a communication pipe where therequest is received.
 66. The mobile device of claim 63, furthercomprising: a super user application configured to temporarily assumemembership of either the first domain based upon approval by the firstdomain owner or the second domain based upon approval by the seconddomain owner.
 67. The mobile device of claim 66, wherein the super userapplication is further configured to modify properties in the firstdomain and the second domain.
 68. The mobile device of claim 63, whereinthe domain controller is further configured to deny the request when thedomain controller determines that the request violates a property mappedto the asset.
 69. The mobile device of claim 68, wherein the propertycomprises any one or more of the following including any combinationthereof: one or more global properties, one or more domain properties,and one or more application properties.
 70. The mobile device of claim63, wherein the operation includes any one or more of the followingincluding any combination thereof: creating a domain, deleting a domain,managing a software application, installing a software application,deleting a software application, managing a property, creating aproperty, reading a property, modifying a property, creating data,reading data, modifying data, or accessing data.
 71. The mobile deviceof claim 63, wherein the first domain comprises a subdomain, wherein thedomain controller is further configured to permit requests from thesubdomain within the first domain.
 72. The mobile device of claim 63,wherein the asset includes at least one of: a communication pipe,persistent data, a property, a software application, a wirelesstransceiver, a user interface, an interface, a connector, a processor, amemory, or a data store.
 73. The mobile device of claim 72, wherein thepersistent data includes any one or more of the following including anycombination thereof: messages, contact information, calendar items, taskitems, configuration information, properties, records, and voice mails.74. The mobile device of claim 63, wherein the request originates fromat least one of: a communication pipe, persistent data, a property, or asoftware application.
 75. The mobile device of claim 63, wherein thedomain controller is further configured to execute error processingoperations subsequent to denying the request.
 76. The mobile device ofclaim 63, wherein the plurality of domains includes a work domain and apersonal domain.
 77. The mobile device of claim 63, wherein theplurality of domains includes a carrier domain.
 78. The mobile device ofclaim 63, wherein the domain controller is configured to process therequest based upon input from the first domain owner and the seconddomain owner.
 79. The mobile device of claim 63, further comprising: anapplication having access to multiple domains.
 80. The mobile device ofclaim 63, further comprising: a messaging application having access tomultiple domains.
 81. The mobile device of claim 63, further comprising:an address book application having access to multiple domains.
 82. Themobile device of claim 63, further comprising: an application configuredto provide a unified view of data across multiple domains.
 83. One ormore non-transitory computer readable media storing instructions thatwhen executed by one or more processors cause the one or more processorsto: segregate a mobile device into a plurality of domains including afirst domain controlled by a first domain owner, and a second domaincontrolled by a second domain owner, wherein the first domain owner isan employer, and the second domain owner is an owner of the mobiledevice; responsive to receiving a request to perform an operation,wherein the operation affects an asset of the mobile device: deny, by adomain controller, the request if the request originated from adifferent domain than the asset; and permit, by the domain controller,the request if the request originated from the same domain as the asset.84. One or more non-transitory computer readable media storinginstructions that when executed by one or more processors cause the oneor more processors to: segregate a mobile device into a plurality ofdomains including a first domain controlled by a first domain owner, anda second domain controlled by a second domain owner, wherein the firstdomain owner is an employer, and the second domain owner is an employeeof the employer; responsive to receiving a request to perform anoperation, wherein the operation affects an asset of the mobile device:deny, by a domain controller, the request if the request originated froma different domain than the asset; and permit, by the domain controller,the request if the request originated from the same domain as the asset.